Public Key Infrastructure (PKI) provides a protocol for implementing authentication using public key cryptography. PKI allows for asymmetric cryptography, wherein different keys are used for encryption and decryption. In particular, a pair of keys, one public and one private is generated for each user for encryption and decryption. To ensure the trustworthiness of public/private keys, certificate authorities (CA) issue digital key certificates. The digital key certificates are digitally signed by the CA to guarantee that an individual providing a digital certificate (also simply referred to herein as certificate) is, in fact, who the individual claims to be. Each digital key certificate includes, among other information, a name of a certificate subject, a serial number, an expiration date, the certificate subject's public key, and the digital signature of the issuing CA. The certificate subject is an entity for which the content of the certificate applies. It is understood that by issuing the certificate, the issuer of the certificate is asserting through the certificate that the content of the certificate applies to the certificate subject. Thereafter, when the certificate subject presents the certificate to relying parties, the relying parties can authenticate the identity of the certificate subject. When the relying party needs to identify a certificate subject, it will perform an activity commonly referred to an authentication. When the relying uses digital certificates to authenticate the certificate subject, the authentication process typically involves two main steps, validating the certificate subject's certificate, and verifying the certificate subject has access to a private key associated with the certificate subject's certificate. This second step is commonly done by validating the certificate subject's signature on various data originated in part by the relying party and subsequently signed by the certificate subject with the private key associated with the certificate subject's certificate.
Digital certificates may need to be revoked prior to expiry. For example, if the certificate subject ceases to be trusted, perhaps because the attributes included in the certificate have changed, or if the certificate subject's private key is stolen or otherwise compromised, signatures made by the certificate subject's private key can no longer be trusted and so the certificate must be revoked. The revoked certificate is published in a certificate status information database, such as a Certificate Revocation List (CRL). When a relying party uses the certificate to authenticate a certificate subject, the relying party may determine the revocation status of the certificate by directly accessing the certificate status information database, such as the CRL or by using an online certificate status protocol (OCSP) or a Server-based Certificate Validation Protocol (SCVP).
Determining the revocation status of a certificate is commonly referred to as determining the status of the certificate, therefore the terms revocation status, status and certificate status are used synonymously herein. Certificate validation commonly refers to a process where the statuses of multiple certificates in a chain are determined. The result of certificate validation is presented in a certificate validation information object that includes an indication of whether to accept or reject the certificate being validated. The process of certificate validation is equivalent to determining the certificate status when there is only one certificate in a chain. The phrase of “determining certificate status” includes functions for determining the certificate validation information object. The phrase “certificate status” includes the status of individual certificates, the status of multiple certificates in a chain, or the certificate validation information object.
The certificate subject may request services offered by the relying party. When the certificate subject requests a service from the relying party, the relying party verifies that authorization attributes associated with the certificate subject match the authorization attributes associated with the requested service. Authorization attributes can be encoded in many forms. For example, authorization attributes may take the form of a predefined Object ID (OID), where multiple parties in a domain have been configured to know that each OID value corresponds to an authorized service or set of services. The OID may take the form of a string of numbers such as 1.2.3.4. When OIDs are represented as a string of numbers it may be known that if, for example, 1.2.3 is authorized for a given certificate subject then 1.2.3.X is also authorized for that certificate subject. Authorization attributes may also take the form of, for example, an index into a table of authorized services, a function name, a role name or identifier, a user name, an X500 Distinguished Name component, a DNS Fully Qualified Domain Name or a component thereof, an IP address or protocol port identifier.
If the certificate subject's authorization attributes match those associated with the requested service, the relying party grants the certificate subject access to the requested service. A match between certificate subject's authorization attributes and the authorization attributes associated with the requested service does not imply that they are identically equal. The relying party could implement at least one predefined rule that determines what is considered as a match and what is not considered as a match. For example, the rule may indicate that a certificate subject's attribute within a predefined range is considered a match with authorization attributes associated with a requested service; a certificate subject's attribute below or above a certain threshold is considered a match with authorization attributes associated with a requested service; a parameter with a particular bit-set is considered a match with the authorization attributes associated with a requested service; and/or the presence or absence of a certain limiting parameter is considered a match with the authorization attributes associated with a requested service.
In some cases the certificate subject's authorization attributes may be included in the digital certificate such that the digital certificate includes an identity attribute that identifies the certificate subject and authorization attributes that identify the certificate subject's privileges. In successfully authenticating the digital certificate, the relying party may therefore be assured of both the identity and authorization attributes of the certificate subject. However, identity and authorization attributes are typically incompatible because the identity attribute is intended to last for a longer time period than authorization attributes, which inherently need to change whenever the privileges of the certificate subject change. By including the authorization attributes into the identity certificate, the certificate subject is required to acquire a new identity certificate whenever the authorization attributes associated with the certificate subject change. Acquiring the identity certificate more often than needed can raise the cost of operating the PKI.
Alternatively, the authorization attribute may be separated from the identity certificate; i.e., the authorization attribute is included in an attribute certificate. One advantage of this approach is that the identity certificate does not need to be updated every time the authorization attributes associated with the certificate subject changes. However, an entirely new system of certificate management is required to manage the attribute certificate.
As an alternative, some organizations use PKI for identity authentication and use a backend server for validating the authorization attributes. Typically, the backend server includes a list of roles with which the certificate subject is associated. These roles are transmitted to the relying party authenticating the certificate subject for the relying party to use in determining which, if any, of the offered services the certificate subject is authorized to access. All of the alternatives presented above require that when the relying party is authenticating the identity and authorization attributes associated with the certificate subject, the relying party must be connected to both the PKI and the attribute certificate management infrastructure. The attribute certificate management infrastructure may include an Authentication, Authorization, and Accounting (AAA) server, a Remote Authentication Dial-In User Service (RADIUS) server, or a Domain Controller.
To eliminate the need for connectivity with the PKI when the relying party is authenticating the certificate subject's identity, one approach allows for each certificate subject to periodically acquire its status from the CRL or to obtain an OCSP status for its certificate from an OCSP server. Thereafter, when presenting its digital certificate to the relying party for authentication, the certificate subject provides a cached copy of its CRL status or the OCSP status to the relying party. If the relying party determines through validation policies the status information is sufficiently current, the relying party may accept the certificate as valid. This approach ensures that the certificate identity status is highly available but it does not provide an avenue for the relying party to validate authorization credentials presented by the certificate subject without connectivity to the attribute certificate management infrastructure.
Accordingly, a method is needed to easily and affordably authenticate both the identity and the authorization attributes of the certificate subject, without requiring connectivity to back-end infrastructure during authentication.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.